<h2>Play with this demo</h2>
<p>
In this Activity, you can : 
<ul>
  <li> start an AsyncTask and see the progress ;
  <li> cancel a started AsyncTask ;
  <li> start an AsyncTask, rotate the device and observe that UI is updated as expected ;
  <li> no more memory leak, you can start as many AsyncTasks as you want.
</ul>
</p>

<p>
Read below to learn more.
</p>

<h2>Advanced AsyncTask usage 2/2. </h2>

<p>
This Activity uses an AsyncTask declared as a static inner class. <br>
The Activity holds a WeakReference on the AsyncTask and the AsyncTask uses a WeakReference on the Activity (2-way weak references).
</p>
        
<h3>Memory leak issue</h3>

<p>
This technique definitely solves the problem : AsyncTask doesn't hold any hard reference to the activity and the other way around.
This way, the AsyncTask itself never prevents the Activity from being garbage collected. There is no memory leak at all using this technique.
</p>

<p>
Nevertheless, the technique proposed here : 
<ul>
  <li>is really heavy and leads to a bloated game of WeakReferences. It would be clearer and lighter to use Loaders.</li>
  <li>uses a deprecated method : <tt>getLastNonConfigurationInstance</tt>. This method is not
available anymore in latest APIs (as it used internally by the Loader Framework of Android) 
and is not available in the support library class FragmentActivity (for the same reason). In support classes, there is a new method called 
: <tt>getLastCustomNonConfigurationInstance</tt> and this prevents us from proposing a general solution to the AsyncTask memory issue).</li>
  <li>although memory management is fine, it is still possible to get a lot of AsyncTasks queued in the ExecutorService (see previous demo for 
  more explanations). AsyncTasks should either be cancelled when rotating the device, or we should prevent another identical AsyncTask to be
  started if one is already running, this leads to more and more complex code to handle all those situations. 
</ul>
</p>

<h3>Conclusion on AsyncTasks</h3>

<p>
This demo Activty illustrates how difficult it is to get a robust implementation of AsyncTasks. It is possible to achieve a working solution with
no memory leak, but not in the same way for all versions of Android (with respect to backward compatibility support library). The conclusion of this serie is that : 
<a href="http://stackoverflow.com/questions/10422697/android-loaders-the-way-to-go">Yes, Loaders are the way to go</a>, just forget AsyncTasks for 
long running asynchronous jobs. 
</p>

<hr>
Loaders offer a more modern implementation of Asynchronous job executions and we will illustrate how to use them in the next serie of this tutorial application.
